1. Field of the Invention
The invention relates to telecommunications exchanges and, more particularly, to a software architecture for use in a stored program controlled telecommunications switching system.
2. History of the Prior Art
In the late 1960s and early 1970s, stored program control (SPC) switching systems were designed primarily around the functions necessary to perform public switched telecommunications network (PSTN) service, that is plain old telephone service (POTS). The SPC telecommunications switches used to render these PSTN services were virtually all designed with a control architecture which separates the parts of the system into functional blocks, each of which perform a separate function in the completion of a call. For example, there are control blocks within a traffic control subsystem of the software which perform digit analysis, route analysis, call supervision, signalling, etc. Each software block performs a certain control function or supervision function within the hardware which contributes to subscriber call setup, supervision, teardown and billing.
Over the years, other special features were added to the POTS services, such as abbreviated dialing, call waiting, and the like, which required the addition of software to the core SPC software operating the switch in order to render these special services.
Stored program control telecommunications switches have evolved over the years into very sophisticated, special purpose, high speed computing machines which include redundant central processors for reliability and remote processors for increased speed and efficiency. A good example of such a switch is the SPC telecommunications switching equipment of the type manufactured by Telefonaktiebolaget L M Ericsson and referred to as the AXE exchange, an earlier version of which is disclosed in the article by Mats Eklund, et al., entitled "AXE 10 System Description," published in Ericsson Review, No. 2, 1976, which is hereby incorporated herein by reference. Another example of such an SPC telecommunications switch is disclosed in U.S. Pat. No. 4,322,843 to H. J. Beuscher, et al. Such switches usually include all of the hardware necessary to perform a number of different telecommunications services. For example, they can be used as local PSTN exchanges, long distance trunking exchanges, private automatic branch exchanges (PABX), all primarily by the installation of specific SPC software to configure them for the required special functions.
As telecommunications services became more sophisticated over the years, new applications for telecommunications exchanges came into existence which required additional special functionality in the software controlling the switch. For example, the growth of cellular radio telephone services has required switching exchanges to serve as mobile switching centers (MSC) for controlling the interconnection of various radio base site controllers (ESC) and allowing mobile subscribers to be passed from cell to cell within the radio network. Similarly, the advent of integrated services digital network (ISDN) services has also required special functionality within switching exchanges in order to render these services to subscribers. While a number of separate specialized exchanges rendering different services to their respective subscribers can be connected together into a communication network, it is very expensive, both in terms of redundant hardware as well as operation and maintenance personnel to provide discrete switches separately programmed with the functionality required for each type of telecommunication service to be rendered.
One approach to reducing the expenses of a telecommunication network is to provide a plurality of different functions in the same switch. This involves the adding of additional software blocks within the control modules of the switch to provide the required functionality for the rendition of each service. Such functionality may relate to special PSTN related services, business group or centrex type (PBAX) services, ISDN services, MSC services and others. The problem with such an approach is that while hardware costs are saved by using the same switch for multiple functions, the software, and particularly the interaction of different software blocks with one another, becomes extremely complex. For example, the addition of one new function may adversely affect or even disable the performance of an existing function in a totally unexpected way. As a result, a large part of the software development costs encountered with such systems in use today are connected with trying to anticipate the effect which new code added to the system will have upon the existing code and the testing and debugging of the overall software system in response to the continued addition of new functionality. The evolution of such "megasystems" of software has dramatically increased the costs of adding new upgrades and new functionality to existing services and has increased the development time of such software to the point that new functions are virtually outdated before they can actually be implemented in the switch. These are not desirable results for the telecommunications companies, their customers, or the ultimate subscribers to the services.
Another approach to adding multiple functions to a telecommunications exchange is that of providing multiple processors and dividing out the software to spread it across the several processors. For example, some systems have proposed to have one processor execute certain function blocks of software and another processor execute other function blocks in order to try and decrease the complexity of the software operating within each processor. While multiple processor systems may have some advantages, such as enhanced throughput and call carrying capacity, there are distinct disadvantages with such systems. For example, where there is a chain of functions required for call setup and those functions are spread across multiple processors, a fault in one processor can disrupt the entire call setup process. In addition, the duplication of hardware, such as the use of multiple processors, increases not only the cost of that hardware but also the cost of other ancillary support and maintenance functions. These disadvantages of multiprocessor systems are present whether the several processors are in the same switch and located on a common bus or whether they are located in separate switches and interconnected by means of a local area network (LAN).
Still another prior art attempt to achieve multiple functionality in a single telecommunications exchange is to simply load multiple functionally oriented software systems into the same switch and compile them as one such as, for example, the loading of a PABX software system directly into a local PSTN switch. Such a combination includes at least one large disadvantage by requiring physical line circuits to perform the interworking between the PABX part and the local PSTN part. In addition, there may be other conflicts between the functionality of the two different software systems and certainly no cooperative sharing of separately accessed common resources.
Thus, it would be great advantage to organize the software within an SPC telecommunication exchange in a manner which allows multiple specific telecommunications applications to be performed with optimum functionality within the same switch. Such an architecture is provided by the system of the present invention.